Method for logical deployment, undeployment and monitoring of a target IP network

ABSTRACT

The method is applied to configure, reconfigure and monitor globally a plurality of network elements (NE 1 , . . . , NE i , . . . , NE j , . . . , NE N ) connected to an IP Network ( 10 ) through multiple interfaces (A 1 , . . . , A N ), with several Network Elements Controllers (NEC 1 , . . . , NEC k , . . . , NEC Q ) connected to the same IP Network ( 10 ) through respective interfaces (B 1 , . . . , B Q ). The IP Network ( 10 ) also provides a plurality of preconfigured IP functional interfaces (C ik ) from each network element (NE i ) to the at least one network elements controller (NEC k ). Each network element (NE i ) has an IP networking layer ( 9 ) and runs/executes several network-related processes (P 1 , . . . , P L ) managed and monitored by this method. The method also provides configuration and monitoring of IP interfaces (D ij ) among network elements. The existing IP functional interfaces (C ik ) are used to perform such managing and monitoring. To get these aims, the method performs high-level actions instead of atomic “get/set” operations. Neither the method neither requires explicit agents-manager paradigm nor depends on a particular communication protocol for network management.

FIELD OF THE INVENTION

The present invention is applied generally to the field oftelecommunication networks and more particularly this invention relatesto configuration, reconfiguration and monitoring of network nodes innetworks providing Internet Protocol (IP) connectivity.

More precisely, the present invention discloses a method for simplifyingthe task of logical deployment to configure a target IP network topologywhich is to be physically deployed on a background IP network, as wellas the inverse task of logical undeployment is simplified. Furthermore,this method allows real time monitoring on the network elementspreviously deployed in, the target IP network.

STATE OF THE ART

Conventional management systems, such as Simple Network ManagementProtocol (SNMP) [D. Harrington, R. Presuhn, B. Wijnen, “An Architecturefot Describing Simple Network Management. Protocol (SNMP) ManagementFrameworks”, IETF Standard 62, RFC 3411, December 2002] or Web BasedEnterprise. Management (WBEN) [Distributed Management Task Force,“Specification of CIM Operations over HTTP”, Version 1.1, DMTF StandardDSP0200, January 2003]) are based on two functional entities: agents andmanagers. Agents run in the devices that are being managed and are awareof the internal information and parameters needed for management.Managers connect to agents in order to perform management operations.

The communication between agents and managers is based in an informationmodel, that is, a structured way of describing the management data (forexample, CPU load, IP addresses, etc.) and a communication protocol toexchange that information. For example, in the case of SNMP managementframework, with SNMP as the communication protocol, the informationmodel is composed of MIBs (Management Information Base) defined in astandardized text-based information structured language called ASN.1(Abstract Syntax Notation 1).

However, these management systems have some drawbacks for the deploymentof global configurations involving several network elements in IPnetworks. On the one hand, they are very strict in terms of requirementsof communication protocol and information model, which are described aspart of the management system. Said communication protocol andinformation model are often incompatible with the communicationinterfaces of devices provided by certain vendors. On the other hand,well-known management systems provide very simple management operations(“get” and “set” in most of the cases), which make said systemsunsuitable for complex configurations. Moreover, when using thesewell-known management systems, each network element is managedindividually, and therefore the management system does not have a globalview of the whole network to be configured.

Solutions to these problems usually, rely on building top-level managerapplications, which act as front-ends of the network management system.However, these applications are difficult to design and implement.

In addition, a currently widely used industrial standard for datainterchange is the eXtensible Markup Language (XML). XML is a World WideWeb Consortium-recommended general-purpose markup language for creatingspecial-purpose markup languages. It is a simplified subset of theStandard Generalized Markup Language (SGML). The primary purpose of XMLis to facilitate the sharing of data across different systems,particularly systems connected via the Internet. Many languages based onXML (for example, Geography Markup Language (GML), RDF/XML, RSS, Atom,MathML, XHTML, SVG, Klip and MusicXML) are defined in a formal way,allowing programs to modify and validate documents in these languageswithout prior knowledge of their particular form.

Network management systems based on XML are described in US 2004/0117452A1. In particular, US 2004/0117452 A1 describes a network managementsystem and method which employs tree-shaped configurations forindividually managed network elements.

With the aim at simplifying the network management, it would bedesirable to provide a straightforward data model that defines theglobal network configuration and eases its management globally, insteadof having managed the individual network elements, without being tied toa particular Configuration of each network element.

The model-focused approach has been already successfully applied toother engineering fields, such as software production in the ModelDriven Architecture (MDA) framework, [Object Management Group, “MDAGuide Version 1.0.1”, OMG Document Number omg/2003-06-01, June 2003],based on technology-agnostic models of software applications andprocessing these models in order to build platform-dependent codeimplementing the desired applications.

On the other hand, a well known management field is Service orientedProvisioning, which requires the network operator to engineer the way inthat services are created and distributed into a network, so that atelecom service provider can define his service offering as a specificset of services. US 2002/0178252 discloses some example of mechanismsfor Service Provisioning. However, implementing Service Provisioning isfocused on the final user (in one end of the network) and does notconsider network topology configuration at all. US 2002/0178252describes a procedural processing of the service configuration based onworkflows and does not consider declarative descriptions ofconfiguration.

In contrast to Service Provisioning, the whole network and not just theuser end must be taken into account in network topology configuration(as a matter of fact, in some management contexts, such asexperimentation infrastructures or testbeds, there is no a final user).Network topology configuration deals with how to define, and configurearbitrary interconnections among network elements, and so declarativedescriptions of the network configuration are required. Declarativedescriptions can be used from a high-level user perspective to describethe configuration wanted by the user, without specification of the meansneeded to get that configuration (this specification of the means usedby the management engine is needed for the service provisioningmechanism disclosed in US 2002/0178252 in the form of workflowdefinitions).

SUMMARY OF THE INVENTION

One aspect of the present invention is a method for logical deploymentof global target network configurations based on a data model definingthe intended global network configuration. In this context, “logical”means that the goal is the deployment of a target network on top of anexiting background network, already physically deployed, takingadvantage of IP technology to build overlay networks. Besides, thisinvention provides complementary methods for logical undeployment andmonitoring of the target IP network in a global way.

The logical deployment of global network configurations according to theproposed method is based on a text-based information structured languagedata model, which describes the intended network configuration globally;distinguishing the present invention from others like the one describedin US 2004/0117452 A1. The text-based information structured languagemay be the standardized XML, so the utilization of this invention bythird-party applications can be flattered. Other possible text-basedinformation structured languages to write the data model may be SGML orASN.1.

Therefore, it is an object of the invention to provide an intuitive anduser-friendly mechanism for automatically configuring and reconfiguringmultiple IP network topologies, involving configuration issues such asnumber of nodes and link connectivity, as well as remotely configuringthe execution of processes at each node (e.g., routing or signallingprocesses).

Note that for establishment and reconfiguration of a desired networktopology, given the usual large size of networks (composed of severaldevices with different pieces of hardware, each one with its ownconfiguration requirements), manual topology reconfiguration results inelevated time consuming and error prone complex tasks. Usually, thesetasks become more critical if the network administrator has to fulfilthem “by hand” using command line interfaces (CLI).

In order to solve and speed up those tedious operations, another objectof the invention is to allow network administrators performing ahigh-level specification of a target network configuration in a flexiblemanner, avoiding spending administration time in carrying out manualconfiguration node by node.

The administrator or user may apply user-friendly XML existing tools toget the specification of a target IP network. Though, he/she is notrequired to produce directly a set of XML files, since the presentinvention may be integrated in a graphical user interface (GUI) just todraw the IP network scenario and logical deploy/undeploy the targetnetwork on a background IP network, including configuration andreconfiguration of the processes to be run at each node of the target IPnetwork.

In addition to the aforementioned tasks, the present invention allowsmonitoring the status of the already logically deployed and workingnetwork, being able to alert the administrator when any element involvedin the IP network (a node, process in a node, or an interface betweennodes) fails or goes wrong.

More concretely, the first aspect of the invention refers to a methodfor logical deployment of a target IP network on a background IPnetwork. The target IP network comprises at least one network element(NE_(N); N≧1) and is supported on the background IP network formed bythe at least one network element (NE_(N)) and at least one networkelements controller (NEC_(Q); Q≧1). The background IP network providesIP functional interfaces (C_(ik)) between the at least one networkelements controller (NEC_(k); k in the 1 . . . Q range) and each networkelement (NE_(i); i=1 . . . N). This method for logical deployment of atarget IP network comprises the steps of:

1^(st) step). Retrieving at the at least one network elements controller(NEC_(k)) at least one process information fragment written in thetext-based information structured language (e.g. XML) for at least oneof said network elements (NE_(i)), said at least one process informationfragment defining the configuration of a network-related process.2^(nd) step) Creating, at said at least one network elements controller(NEC_(k)), a command script for each network element (NE_(i)), being thecommand script a list of operations in terms of the functional interface(C_(ik)) and the operations which are to be executed in that particularnetwork element using the respective functional interface (C_(ik)) bythe corresponding network elements controller (NEC_(k)). At this stepthe content of the command script may be void.3^(rd) step) Generating or deriving from said process informationfragment at least one configuration template, for the configuration ofat least one network-related process and for at least one of the networkelements.4^(th) step) Adding at least a command to the command scriptcorresponding to said at least one network element, for starting each ofsaid at least one network-related process using said configurationtemplate.5^(th) step) Pushing each of the configuration templates from thenetwork elements controller (NEC_(k)) to the respective network element(NE_(i)); pushing means sending the configuration templates from thenetwork elements controller (NEC_(k)) through the correspondingfunctional interfaces (C_(ik)) and storing said configuration templatesat said corresponding network element NE_(i)).6^(th) step) Executing the command script for said network element(NE_(i)) in a remote mode through the respective functional interface(C_(ik)) (i=1, . . . , j, . . . , N), which consists of any IP-basedprotocol allowing the remote executions of commands, either one-by-oneor in a batch mode.

The IP functional interfaces (C_(ik)) between a network element (NE_(i))and the respective network elements controller (NEC_(k)) may be one ofthe standard protocols: RLOGIN, TELNET, SSH, TL1, RPC, RMI, XML-RPC,HTTP, SOAP, CORBA, COM+ and SNMP.

Regarding configuration templates, they are defined as pieces ofinformation that need to be pushed (sent and stored) to networkelements, so that their network-related processes can work properly whenthey are started (for example, configuration templates containparameters to be read by a network-related processes when started).

Optionally, the method for logical deployment of the target IP networkmay include in the mentioned fourth step of adding commands to commandscripts at said at least one network elements controller (NEC_(k))further adding a command for setting an IP interface (D_(ij); obviously,here i≠j, i=1 . . . N, j=1, . . . N) between two network elements(NE_(i), NE_(j)). These commands for setting an IP interface (D_(ij))are added to each of the two command scripts corresponding to said twonetwork elements (NE_(i), NE_(j)) and before the commands used forstarting the network-related processes (as specified in step 4). In sucha case, at step 6 of this method for logical deployment, it is clearthat said commands are executed remotely, as part of the twocorresponding scripts, through the respective functional interface(C_(ik), C_(jk)) of the network elements controller (NEC_(k)) withnetwork element (NE_(i)) at its first end and network element (NE_(j))at its second end respectively.

The so-called network-related processes, to be started at the networkelements (NE_(N)) may be selected from a group of: routing daemons,servers, service platforms, hardware controllers, management agents,reservation protocol daemons and link resource management deamons. Someof these network-related processes needs to use the corresponding IPinterface (D_(ij)) for their operation. There can be alsonetwork-related processes started at a network element (NE_(i)) thatoperate without involving any previous set of an IP interface (D_(ij))with another network element (NE_(j)).

In this context, a “daemon” is a process continuously running inbackground performing a particular, task, A “server” is a particularkind of daemon that listens for request from network clients, processthem and send a response back to the client, implementing a particularservice.

Thus, the described method allows the configuration of all needed IPinterfaces (D_(ij)) between pairs of network elements (NE_(i), NE_(j)),and their specification is defined as part of the target IP network. Theparticular information defining the IP interfaces (D_(ij)) depends onthe particular IP connection type (direct or tunnelled), the IPnetworking protocol version (IPv6, IPV4), on the layer 2 or link layeraspects (Ethernet switching for Virtual Local Area Networks—VLANs—,virtual circuit technologies, etc.).

Furthermore, after having a target IP network deployed according to thesteps for logical deploying as described before or by anotherconventional method for network configuration, another aspect of theinvention refers to providing in a similar intuitive way a method forlogical undeployment of a target IP network comprising at least onenetwork elements (NE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N))belonging to the previously deployed target IP network.

This method for logical undeploying comprises the following steps:

1^(st) step) Retrieving at the at least one network elements controller(NEC_(k)) at least one process information fragment written in atext-based information structured language, for at least one of thenetwork elements (NE_(i)), said at least one process informationfragment defining a, network-related process;2^(nd) step) Creating a command script for each of said network elements(NE_(i)) at one (or more if necessary) corresponding network elementscontroller (NEC_(k)),3^(th) step) Adding at least a command to the command script generatedat the corresponding network elements controller (NEC_(k)), being saidcommands defined for stopping each of the at least one network-relatedprocess started for at least one network element (NE_(i)); and4^(th) step) Remotely executing through the respective functionalinterface (C_(ik)) the command script for the at least one networkelement (NE_(i)), (i=1, . . . , j, . . . , N).

If an at least one IP interface (D_(ij)) has been specified between apair of network elements (NE_(i), NE_(j)) in the logical deployment ofthe target IP network, the step of adding commands to command script atsaid at least one network elements controller (NEC_(k)) furthercomprising:

adding a command for unsetting the IP interface (D_(ij)) between thenetwork elements (NE_(i), NE_(j)) to each of the two respective commandscripts and said commands are added to the command script after the onesused for stopping the network-related process (as specified in step 3).

Another capability of this invention is a global monitoring of thetarget IP network. Hence, a method for logical monitoring of a target IPnetwork is proposed here and allows a network administrator checking thestatus of the network-related processes for the network elements fromsaid target IP network, which has been previously deployed by either thealready described method for logical deployment or another conventionalmethod for network configuration. The method for logical monitoringcomprises the following steps, after steps of retrieving the neededprocess information fragments and creating new command scripts at thecorresponding network elements controller (NEC_(k)) for each networkelement (NE_(i)) as explained before:

adding at least a command to the command script generated at thecorresponding network elements controller (NEC_(k)) for checking thestatus (active or inactive, running, killed, . . . ) of each of the atleast one network-related process started for at least one networkelement (NE_(i)); and

remotely executing through the respective functional interface (C_(ik))the command script for the at least one network element (NE_(i)), (i=1,. . . , j, . . . , N).

Additionally, the method for logical monitoring allows an administrator,if at least one IP interface (D_(ij)) is previously set and needed,monitoring the IP interface (D_(ij)) between any two network elements(NE_(i), NE_(j)). In order to check this IP interface (D_(ij)), ping isperformed to test Whether the particular pair of network elements(NE_(i), NE_(j)) at each end of said IP interface (D_(ij)) is reachableacross the IP network. Thus, this method comprises the step of:

at said at least one network elements controller (NEC_(k)), adding atleast a ping command for the IP interface (D_(ij)) to each of the twocommand scripts corresponding to the two interface ending networkelements (NE_(i), NE_(j)).

The ping commands are added to each command script preferably before thecommands used for checking the status of the network-related processes.The step for pinging further comprises sending Echo messages accordingto the standardized Internet Control Message Protocol (ICMP), which isone of the core protocols of the Internet protocol suite chiefly used bynetworked computers' operating systems to send errormessages-indicating, for instance, that a requested service is notavailable or that a network element could not be reached. In particular,the method for monitoring performs the following message exchanges inthe pinging step:

sending an ICMP Echo Request message to first end of said interface(D_(ij)) at one of the network elements (NE_(i)) and listening for ICMPEcho Response message replied from said network element (NE_(i)) for adetermined or pre-selected time, said ICMP Echo Request sent from theother network element (NE_(j)); and,

if an ICMP Echo Response message is received from said network element(NE_(i)) within said determined time:

sending an ICMP Echo Request message to second end of said interface(D_(ij)) at the other network element (NE_(j)) and listening for ICMPEcho Response message replied from said network element (NE_(j)) for adetermined time (usually applying the same time constraints for bothnetwork elements), said ICMP Echo Request sent from the first end ofsaid interface (D_(ij)) at corresponding network element (NE_(i)).

There are other aspects of the present invention which refer toproviding respective methods for logical deployment, undeployment andmonitoring of a target IP network on a background IP network just toimplement the setting, unsetting or monitoring respectively of a IPinterfaces (D_(ij)), (i≠j). Obviously, these IP interfaces (D_(ij)) canbe used by network-related processes that can be either configured at apair of network elements (NE_(i), NE_(j)) of the target IP networkaccording to the method for logical deployment described firstly or byemploying another conventional method for network configuration which issuitable for managing network-related processes over the background IPnetwork.

Thus, it is provided a method for logical deployment of a target IPnetwork on a background IP network which comprises the steps of:

1^(st) step) Retrieving at the at least one network elements controller(NEC_(k)) a IP networking information fragment written in a text-basedinformation structured language for at least a pair of network elements(NE_(i), NE_(j)), said IP networking information fragment defining a IPnetworking layer (INL). The IP networking layer, also known as networklayer and sometimes called the Internet layer, handles the movement ofpackets around the network [“TCP/IP Illustrated, Volume 1: TheProtocols”, by W. Richard Stevens, Addison-Wesley, Chapter 1.2, page 2,1994]. This layer and, more particularly, the IP networking informationfragment comprises the specification of:

-   -   interfaces provided by each network element (NE_(i)) and        connection to the other network elements (NE_(j)) through said        interfaces: here called IP interfaces (D_(ij)),    -   IP address (and mask) for each one of said interfaces (D_(ij)).        2^(nd) step) Creating, at said at least one network elements        controller (NEC_(k)), a command script for each of said network        elements (NE_(i), NE_(j)).        3^(th) step) Adding at least a command for setting an IP        interface (D_(ij)) between said two network elements (NE_(i),        NE_(j)) to each of the command scripts corresponding to the pair        of network elements (NE_(i), NE_(i)), using said IP networking        information fragment, at said at least one network elements        controller (NEC_(k)).

Correspondingly, a method for logical undeployment of a target IPnetwork is here described, said target IP network already deployed bythe very previous method for logical deployment or another conventionalmethod for IP interfaces configuration, in which at least an IPinterface (D_(ij)) between two network elements (NE_(i), NE_(j)) hasbeen set. This method for logical undeployment comprises steps forretrieving the IP networking information fragment at the correspondingnetwork elements controller (NEC_(k)) and creating, at said at least onenetwork elements controller (NEC_(k)), new command scripts for each ofsaid network elements (NE_(i), NE_(j)), and then perform the step of:

-   -   adding to each of the command scripts corresponding to the pair        of network elements (NE_(i), NE_(j)) at least a command for        unsetting the IP interface (D_(ij)).

And the invention also provides with a method for logical monitoring ofa target IP network already deployed in which at least an IP interface(D_(ij)) between two network elements (NE_(i), NE_(j)) has beenpreviously set according to the three steps explained before for theprevious method for logical monitoring or according to anotherconventional method for IP interfaces configuration, which allows toknow whether the IP interface (D_(ij)) is enabled or, on the contrary,any failure occurs on reaching any of the two network elements (NE_(i),NE_(j)) across said IP interface (D_(ij)). In order to get suchproposal, this method for logical monitoring comprising steps forretrieving the IP networking information fragment at the correspondingnetwork elements controller (NEC_(k)) and creating, at said at least onenetwork elements controller (NEC_(k)), new command scripts for each ofsaid network elements (NE_(i), NE_(j)), and then perform the step of:

-   -   adding to each of the command scripts created for the pair of        network elements (NE_(i), NE_(j)) at least a command for pinging        the IP interface (D_(ij)) between the two network elements        (NE_(i), NE_(j))—as explained before for the pinging step—.

It is another aspect of the present invention to provide a computer,program comprising computer program code means adapted to perform thesteps of (any or even all of) the described methods, when said programis run on a central processing unit or processor of a computer, ageneral purpose processor, on a digital signal processor, afield-programmable gate array, an application-specific integratedcircuit, a micro-processor, a micro-controller, or any other form ofprogrammable hardware.

It is further another aspect of the present invention to provide anetwork node comprising IP networking means for communication to atleast another node and processing means adapted to perform the steps ofany of the methods proposed. Such network node, at which any or even allof the described methods for logical deploy/undeploy/monitoring can beimplemented, is what is denominated here like network elementscontroller (NEC), provided with means for communication with anothernodes so-called network elements (NE). These network elements andnetwork, elements controllers are nodes from an IP network, here theso-called background IP network.

And it is another aspect of the present invention to provide atelecommunications network comprising at least one of these nodes actingas network elements controllers (NEC).

The main advantages and innovations of the proposed invention becomeapparent in the description and are summarized as follows:

1. Multiple (per managed device) remote access interfaces vs. fixedexplicit communication protocols: The invention described in thisdocument neither defines a particular communication protocol, norimposes any restriction in the communication interface of the configuredelements, as a conventional management system does (like SNMP or HTTP).Instead, the present invention reuses as communication protocol anyexisting remote access interface the managed device is providing (likeTelnet, SSH or TL1), here called as IP functional interface (C_(ik)). Infact, multiple remote access types can be used seamlessly, since eachnetwork element (NE_(i)) (managed device) can provide a different IPfunctional interface (C_(ik)) with the corresponding network elementscontroller (NEC_(k)) in the same background IP network.

2. There are no explicit agents: As explain for invention background, inthe current state of the art, conventional management systems needrunning a dedicated process in the managed device in order to deal withthe communication protocol queries from the manager and providing aninterface to the device internal data and parameters. This impliescomplexity (different agents need to be developed, for differentdevices) and inefficiency (the agent process consumes resources in themanaged device). On the contrary, the present invention does not useexplicit agent processes, allowing the manager direct access to data andparameters through the remote access or IP functional interfaces.

3. High-level actions and module-oriented in the global network vs.low-level actions and object-oriented in individual network elements:Conventional management systems are based on atomic actions (“get”,“set”, etc.) applied to elemental data objects (for example, the IPaddress of the managed device) in individual network elements.Therefore, a user-oriented manager has to integrate many atomic actionsto perform high-level management tasks in order to provide globalnetwork configurations and the development of such manager could becomplex. The present approach is easier and more intuitive because it isbased on high-level actions (deploy, undeploy and monitor) and softwaremodules (i.e., a process) instead of low-level actions and atomic objectorientation subjects.

BRIEF DESCRIPTION OF THE DRAWINGS

To complete the description and in order to provide for a betterunderstanding of the invention, a set of drawings is provided. Saiddrawings form an integral part of the description and illustrate apreferred embodiment of the invention, which should not be interpretedas restricting the scope of the invention, but just as an example of howthe invention can be embodied. The drawings comprise the followingfigures:

FIG. 1 is a schematic representation of a target IP network comprising aplurality of network elements (NE₁, . . . , NE_(i), . . . , NE_(j), . .. , NE_(N)) supported on a background IP network composed of thesegathered network elements and at least one network elements controller(NEC₁), in accordance with an embodiment of the present invention.

FIG. 2 is a detail of the architecture of one network element (NE_(i)),showing the interfaces with other network elements (NE_(j)) and othernetwork elements controller (NEC_(k)).

FIG. 3 is a schematic representation of a target network configurationstructure formed by XML modules from a data model, in accordance with apreferred embodiment of the present invention.

FIG. 4 shows a workflow of the invention, specifying the sequence ofactions that need to be performed for deploying, monitoring orun-deploying of a particular global network configuration (for instance,the target IP network from FIG. 1).

FIG. 5 a-5 d, put all together, represent a flowchart of a toolimplemented at the network elements Controller (NEC_(k)) performing, inaccordance with the preferred embodiment of the present invention, thesteps for logical deployment (partially illustrated in FIG. 5 a),undeployment (partially illustrated in FIG. 5 b, where the commoninitial step of retrieving from the data module information fragmentsfor deploy/undeploy or monitoring is drawn), and monitoring (partiallyillustrated in FIG. 5 c), being the final common step of remotelyexecution of commands drawn in FIG. 5 d.

DETAILED DESCRIPTION OF THE INVENTION

Here below a practical implementation of the invention is described,which is based on the general network architecture shown in FIG. 1. Thisgeneral network architecture gathers:

-   -   several network elements (NE₁, . . . , NE_(i), . . . , NE_(j), .        . . , NE_(N)) connected to an IP Network (10) through a        plurality of interfaces (A₁, . . . , Ai, . . . , A_(j) . . . ,        A_(N)), and    -   several Network Elements Controllers (NEC₁, . . . , NEC_(k), . .        . , NEC_(Q)) connected to the same IP Network (10) through        another plurality of interfaces (B₁, . . . , B_(k), . . . ,        B_(Q)).

These interfaces (A₁, . . . , A_(N), B₁, . . . , B_(Q)) on the IPNetwork (10) with the network elements (NE₁, . . . , NE_(i), . . . ,NE_(j), . . . , NE_(N)) and Network Elements. Controllers (NEC₁, . . . ,NEC_(k), . . . , NEC_(Q)) respectively could be all of the same type,for example, Ethernet interfaces.

This IP Network (10) also provides a plurality of IP functionalinterfaces (C_(ik)) from each network element (NE_(i)) to the at leastone network elements controller (NEC_(k)). The configuration of thesefunctional interfaces is not provided by the invention, they aresupposed pre-configured, previously to the application of the methoddescribed in this document.

FIG. 1 only shows one Network Elements Controller (NEC₁) for the sake ofclarity, but in a general, case there would be as many as desired(NEC_(k)), each one with its own C_(1k), . . . , C_(Nk), interfaces.

The IP Network (10) constitutes an existing background IP network overwhich is defined a target IP network by the multiple network elementsNE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N)) to be managed.

Each network element (NE_(i)) has a modular architecture, as depicted inFIG. 2, that implements an IP networking layer (9) and runs/executesseveral (L, with L≧0) network-related processes (P₁, . . . , P_(L)). TheIP networking layer (9) can be configured to provide IP interfaces(D_(ij)) from any of the network element (NE_(i)) to another one(NE_(j)), being i and j any non equal integers in the 1, . . . , Nrange. The configuration of these IP interfaces (D_(ij)) is provided bythe method described in this document.

Note that actual implementations of this invention may not implementalthe possible interfaces specified in the general description. Forexample, in a practical implementation with four network elements maybeonly four IP interfaces (for example: D₁₂, D₂₃, D₃₄, and D₁₄) could beconsidered, instead of all the resting possible ones: D₁₃, D₁₄, D₂₁,D₂₃, D₂₄ and D₃₄.

An example of application could be configuration of a dynamicallyswitched optical transport network, where the network elements are:

-   -   Optical Connection Controllers (OCC) implemented in computers        and constituting the control part of physical optical nodes,    -   A Link Emulator device    -   Ethernet Switches    -   A router-broadband-tester with vendor-specific technology

In that example, the IP functional interfaces (C_(ik)) are based eitherin SSH—for the OCCs and link emulator—, Telnet—for the switches—orRPC—provided by vendor for the router tester device—. There are threekinds of IP interfaces (D_(ij)): OCC-OCC directly connected through realoptical fibber, OCC-OCC not using network constraints—through adedicated VLAN—, OCC-OCC using network constraints—through link emulatordevice—and OCC-broadband tester—through a dedicated VLAN—. Each OpticalConnection Controller runs five network-related processes (then, L=5 inthis example): Optical Link Resource Manager (OLRM), Link ResourceManager (LRM), the Open Shortest Path First (OSPF) routing protocol, theResource Reservation (RSVP) signalling protocol and SNMP managementprotocol. The broadband tester runs a RSVP process.

Using a text-based information structured language such as XML, a globalnetwork configuration can be specified, defining a plurality ofinformation Modules (M₀, M₁, . . . , M_(L)) that determines a targetnetwork configuration structure (7), drawn in FIG. 3. There are processinformation modules (M₁, . . . , M_(L)) describing each one of the Lnetwork-related processes (P₁, . . . , P_(L)) along as one moreinformation module specifying the IP networking configuration needed inthe target network configuration structure (7) and here called IPnetworking information module (M₀). The present invention provides anuser/administrator with means for logical deployment, of this globalnetwork configuration into the corresponding network elements (NE₁, . .. , NE_(i), . . . , NE_(j), . . . , NE_(N)) using the pre-configured IPfunctional interfaces (C_(ik)) with at least one of the network elementscontroller (NEC₁, . . . , NEC_(k), . . . , NEC_(Q).

Each information module (M₀, M₁, . . . , M_(L)) is composed of N+1sections: there are N sections (NE₁sec, . . . NE_(i)sec, . . . ,NE_(N)sec), corresponding to each one of the network elements (NE₁, . .. , NE_(i), . . . , NE_(j), . . . , NE_(N)) and a global section (Gsec)including configurations elements involving several network elements(NE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N)). Empty sectionsare allowed, but each module (M₀, M₁, . . . , M_(L)) must include atleast one section.

A particular set of IP networking information module (M₀) plus processinformation modules (M₁, . . . , M_(L)) realization consists of, forexample, a set of L+1 XML files stored in the hard disk of any of thenetwork elements controller (NEC₁, . . . , NEC_(k), . . . , NEC_(Q)).Another implementation alternative is a group of records in a XML-baseddistributed database.

The possible embodiments of the target network configuration structure(7) define a XML-based data model. Building, storing and retrieving oftarget network configurations from the XML-based data model is out ofthe scope of this patent. Network administrators can use any suitableXML tool or database interface, for example, a graphic user interfaceprogram or a database manager program for these purposes.

The retrieved XML-based data model structured in the L+1 informationmodules (M₀, M₁, . . . , M_(L)) specifies the global networkconfigurations to be deployed. The user/administrator can retrieve theneeded process information fragments from the process informationmodules (M₁, . . . , M_(L)) describing each one of the L network-relatedprocesses (P₁, . . . , P_(L)) for the set of network elements at whichthese processes (P₁, . . . , P_(L)) are required to be configured forthe target network configuration. Thus, a process information fragmentis a set of sections from a process information module, so also writtenin XML or the text-based, information language used to specify theglobal network configuration. Likewise, in order to configure the IPinterfaces (D_(ij)) to be provided by the IP networking layer (9), theuser/administrator can retrieve the needed IP networking fragmentsconsisting of a set of sections from the IP networking informationmodule (M₀).

Each information module (M₀, M₁, . . . , M_(L)) of the XML data modelconforms to a Document Type Definition or XML Schema. The Document TypeDefinition (DTD) is a standard language developed primarily for theexpression of a schema via a set of declarations that conform to aparticular markup syntax. It describes a type of documents written in atext-based information structured language (SGML, XML) in terms ofconstraints on the structure of those documents. XML Schema is similarto DTD, accomplishing the same purpose. Hence, the DTD/XML Schema is adescription of a type of XML documents, typically expressed in terms ofconstraints on the structure and content of documents of that type,above and beyond the basic syntax constraints imposed by XML itself. TheDTD/XML Schema provides a view of the document type at a relatively highlevel of abstraction and is used for validation purposes during theworkflow of the method for logical deployment, undeployment andmonitoring described as follows and in accordance to FIG. 4.

More in detail, these information modules (M₀, M₁, . . . , M_(L)) fromthe XML data model include:

-   -   The IP networking information module (M₀) with specifications of        the IP networking layer (9) to support the IP interfaces        (D_(ij)) comprises:        -   N sections (NE₁sec, . . . NE_(i)sec, . . . NE_(N)sec)            including:        -   Reference to the network element (NE_(i)) index (i=1 to N).        -   The IP functional interface (C_(ik)) that each network            elements controller (NEC₁, . . . , NEC_(k), . . . , NEC_(Q))            uses to access the network element (NE_(i)). However, this            is not the unique possibility and other implementations of            the invention could not include the IP functional interface            (C_(ik)) related information in the IP network information            module (M₀). For instance, this information could be used            implicitly by the software application implementing the very            network elements controller (NEC_(k)) maybe, implemented in            some configuration file or database of said network elements            controller (NEC_(k)), which is out of the scope of this            invention.        -   A global section (Gsec) must include:        -   The specification of all IP interfaces (D_(ij)) defined as            part of the target IP network, depending upon the particular            IP interface requirements (connection type, etc.).    -   The process information modules (M₁, . . . , M_(L)) with        specifications of the network-related processes (P₁, . . . ,        P_(L)) comprises:        -   N sections (NE₁sec, . . . NE_(i)sec, . . . NE_(N)sec)            including:        -   Reference to the network element (NE_(i)) index (i=1 to N).        -   The configuration for the process running in the NE. The            particular information depends on the particular process.        -   All the necessary information regarding the process            environment in network element (NE_(i)), for each, one of            the network-related processes (P₁, . . . , P_(L)); although            if a particular process is not to be set in that network            element (NE_(i)), it could be omitted. This information            depends on the particular process type and the hardware            platform of the network element—computer, host, router,            etc.—but could include starting and stopping commands,            pathname to the binary file implementing the process,            location of configuration files, etc.        -   A global section (Gsec) pet network-related processes            including:        -   Configuration elements that could affect as several process            instances running in several network elements. It is up to            the network administrator to use this section to include            common configurations for several instances of the process            in all network elements (for example, considering a dynamic            routing process and supposing that all the instances uses            the same routing algorithm configuration, such configuration            could be defined in the global section).

Given a particular XML data model to be applied to a particular IPnetwork architecture, the actions taken for logical deploying,undeploying and monitoring that particular IP network follow theworkflow of FIG. 4:

-   -   (1) Previous to the application of the corresponding method, a        target network configuration must be provided by the user by        means of any suitable XML tool or database interface in order to        do so and it will depend on how the target network        configurations are built, stored and retrieved (out of the scope        of this patent).    -   (2) User interacts with network elements controller (lets say        NEC_(k)) in order to perform a particular action. There are        three possible actions: DEPLOY, to establish the configuration        in the network elements; UN-DEPLOY, to clear the configuration        in the network elements, reverting the network to an        un-configured state; and MONITOR, to check the status of IP        interfaces (D_(ij)) and network-related processes in each        network element (NE₁, . . . , NE_(i), . . . , NE_(N)). In        addition, the user specify the subset of the L+1 information        modules: to which the action will be applied. The interface        between users and network elements controller (NEC_(k)) is out        of the scope of this patent.    -   (3) Upon command, an engine module (8) at network elements        controller (NEC_(k)) retrieves the required target network        configuration from the XML data model. The retrieval of the        target network configuration data is out of the scope of this        patent. If the engine module (8) is unable to retrieve all the        needed modules of the target network configuration; it reports        the error to user and the workflow ends.    -   (4) The engine module (8) processes the target network        configuration, performing several actions in sequence:        -   a. Engine (8) validates the XML data modules against DTD/XML            Schema. If validation is unsuccessful, it reports the error            to user and the workflow ends.        -   b. If the validation is successful, the engine (8) generates            command scripts in a per network element basis and            configuration templates (in a per network element and            network-related process basis). Command scripts are            sequences of commands expressed in terms of the IP            functional interface (C_(ik)) that will lead, upon execution            in each network element, to the desired action (set up or            deploy, set down or un-deploy, and monitor). Configuration            templates are pieces of information that need to be pushed            to network elements so that their network-related processes            can work properly (for example, a configuration template            could be a file that the process needs to read when it            starts).        -   The target network configuration must contain all the needed            information and parameters (maybe implicitly) in order to            build the command scripts and configuration templates needed            to implement the required action (deploy, un-deploy or            monitor). Otherwise, this condition is reported to the user            as error and the workflow ends.    -   (5) Configuration templates are pushed to each NE₁, . . . ,        NE_(i), . . . NE_(N) using the IP functional interface (C_(ik))        with the network elements controller (NEC_(k)).    -   (6) Command scripts are executed in each NE, in a remote mode        using the IP functional interface (C_(ik)).

Finally, the user is reported on the result of the action. In the caseof monitor action, this includes information about the status of the IPinterfaces (D_(ij)) and network-related processes.

The engine (8) constitute an implementation at one network elementscontroller (NEC_(k)) of the three complementing methods for logicaldeployment, undeployment and monitoring of a target IP network,respectively performing configuration, reconfiguration or monitoring ofnetwork-related processes (P₁, . . . , P_(L)) and also the IP interfaces(D_(ij)) that may be used by said network-related processes (P₁, . . . ,P_(L)).

The steps executed in the engine (8) at a network elements controller(NEC_(k)) follow the flowchart split in three branches corresponding toactions of logical deployment, undeployment, and monitoring, depicted inFIGS. 5 a, 5 b and 5 c respectively, altogether with a last branch thatjoins the previous three branches into the end of the flowchart.

The step of adding commands to the command script for setting an IPinterface (D_(ij)) between two network elements (NE_(i), NE_(j))comprises:

allocating an IP address at first end of said interface, (D_(ij)) at oneof the network elements (NE_(i));

allocating an IP address at second end of said interface (D_(ij)) at theother network element (NE_(j)).

If said IP interface (D_(ij)) between the two network elements (NE_(i),NE_(j)) is a VLAN switched Ethernet based interface, that step furthercomprises the operations of:

establishing a VLAN identifier at first end of said interface (D_(ij))at one of the network elements (NED;

establishing a VLAN identifier at second end of said interface (D_(ij))at the other network element (NE_(j)).

In case that the IP interface (D_(ij)) between two network elements(NE_(i), NE_(j)) is implemented by means of an IP-based tunnel, such asGRE, IPSec or IP-over-IP, it is established a configuration of the twoends of said IP tunnel, said two ends corresponding to the two networkelements (NE_(i), NE_(j)).

In another possible case, when the target IP network is based on somevirtual circuit techonology, like MPLS (Multiprotocol Label Switching),GMPLS (Generalized Multiprotocol Label Switching), ATM (AsynchronousTransfer Mode) or Frame Relay, there are more additional operations insaid step in order to establish the virtual circuit or path (forexample, in the case of MPLS, setting valour for label identifying thevirtual circuit in the MPLS overlaid network).

If establishment of the IP interface (D_(ij)) needs configuration in atleast some other intermediate network element (NE_(p)) different fromNE_(i) or NE_(j) (lets said NE_(p) with p≠i and p≠j), said configurationis added to the command script of the at least said other intermediatenetwork element (NE_(p)). This is the case when VLAN switches Ethernetbased interfaces needing establish configuration in intermediateEthernet switches or tunnel interfaces are used and so it is needed toconfigure all the network elements providing the tunnel.

In the step of adding commands to the command script for startingnetwork-related processes, the command added consist merely in a shellcommand of the operating system if UNIX or compatible operating systemis running in the NE.

Inversely, for logical undeployment, in the step of adding commands tothe command script for stopping network-related processes, the commandadded can be the kill UNIX command, if UNIX or compatible operatingsystem is running in the NE.

For logical undeployment, the step of adding commands to the commandscript for unsetting the IP interface (D_(ij)) between two networkelements (NE_(i), NE_(j)) further comprises:

removing the IP address allocated at first end of said interface(D_(ij)) at one network element (NE_(i));

removing an IP address allocated at second end of said interface(D_(ij)) at the other network element (NE_(j)).

And depending on the kind of the IP interface (D_(ij)), this step forunsetting said IP interface (D_(ij)) correspondingly includes removingthe configuration of the VLAN identifiers, the two ends of the IP-basedtunnel or the virtual circuit established before and, in such a casethat any other intermediate, network element (NE_(p)) different fromNE_(i) or NE_(j) (lets said NE_(p) with p≠i and p≠j) is involved,removing the configuration of each intermediate network elements(NE_(p)) previously set to provide said IP interface (D_(ij)).

With regards to monitoring, the step for pinging the IP interface(D_(ij)) between two network elements (NE_(i), NE_(j)) is based on ICMPecho messages, which are built at networking layer and then encapsulatedas datagrams to be retransmitted. Hence, monitoring of IP interface(D_(ij)) is independent from the subjacent technology, since ping isbased on IP address whose allocation is always required for setting theIP interface (D_(ij)), independently from its implementation—VLAN overEthernet, GRE, IPSec or IP-over-IP, MPLS, GMPLS, ATM, Frame Relay, . . .—.

Besides, in order to monitor the network-related processes (P₁, . . . ,P_(L)) deployed at the corresponding network element (NE_(i)), in thestep of adding at least a command to the command script for networkelement (NE_(i)), the command added consists merely in the pidof commandin case that UNIX or compatible operating system is running in theNE_(i). The pidof command is a UNIX utility that returns a processidentifier (PID) of a running process, that is, monitoringnetwork-related processes (P₁, . . . , P_(L)) by regards to checking aparticular network-related process belongs to the running process listbeing executed by the operating system kernel, at the network element(NE_(i)).

Remote execution of command scripts through the IP functional interface(C_(ik)) depends on the type of said preconfigured IP functionalinterface (C_(ik)). For instance, if the IP functional interface(C_(ik)) is based on RPC or Telnet, the commands added to the commandscript generated at the network element controller (NEC_(k)) areexecuted one by one in sequence at the corresponding, network element(NE_(i)). In case of SSH, a mixed mode is applied for remote executionof command scripts, which comprises copying firstly the script file tothe network element (NE_(i)) and, next; a command sent by networkelement controller (NEC_(k)) is executed through the SSH interface inorder to execute that script file—stored in the hard disk of saidnetwork element (NE_(i)) or any other storing media—. In this case,being IP functional interface (C_(ik)) implemented as SSH, the commandscript are just a list of shell commands.

The SSH interface can also be used to push configuration templates tothe respective network element (NE_(i)) by copying firstly a filegenerated at the network element controller (NEC_(k)) with theconfiguration template derived from, the proper process informationfragment P₁, . . . , P_(L)) to the network element (NE_(i)), since SSHallows sending files from the network element controller (NEC_(k)) tosaid network element (NE_(i)).

In this text, the term “comprises” and its derivations (such as“comprising”, etc.) should not be understood in an excluding sense, thatis, these terms should not be interpreted as excluding the possibilitythat what is described and defined may include further elements, steps,etc.

The invention is obviously not limited to the specific embodimentsdescribed herein, but also encompasses any variations that may beconsidered by any person skilled in the art (for example, as regards thechoice of components, configuration, etc.), within the general scope ofthe invention as defined in the appended claims.

Some preferred embodiments of the invention are described in thedependent claims which are included next.

1. Method for logical deployment of a target IP network comprising aplurality of network elements (NE₁, . . . , NE_(i), . . . , NE_(j), . .. , NE_(N)) capable of running network-related processes and supportedon a background IP network which comprises said network elements (NE₁, .. . , NE_(i), . . . , NE_(j), . . . , NE_(N)) and at least one networkelements controller (NEC₁, . . . , NEC_(k), . . . , NEC_(Q)), thebackground IP network providing IP functional interfaces (C_(ik))between the at least one network elements controller (NEC_(k)) and eachnetwork element (NE_(i)), the method comprising the steps of: retrievingat the at least one network elements controller (NEC_(k)) at least oneprocess information fragment written in a text-based informationstructured language for each network element (NE_(i)), said at least oneprocess information fragment defining one network-related process andbeing part of a target network configuration structure; creating, bysaid at least one network elements controller (NEC_(k)), a commandscript for each network element (NE_(i)) based on the target networkconfiguration structure and to be executed at the corresponding networkelement (NE_(i)); generating, from said at least one process informationfragment, at least one configuration template for at least onenetwork-related process and for each network element (NE_(i)), to beused at the corresponding network element (NE_(i)); adding at least acommand for setting an IP interface (D_(ij)), based on the targetnetwork configuration structure, between two network elements (NE_(i),NE_(j)) to each of the two command scripts corresponding to said twonetwork elements (NE_(i), NE_(j)); adding to the command script for eachnetwork element (NE_(i)), after adding the commands for setting the IPinterface (D_(ij)), at least a command for starting the at least onenetwork-related process using the corresponding configuration template;sending each configuration template from said at least one networkelements controller (NEC_(k)) to the corresponding network element(NE_(i)) through the respective functional interfaces (C_(ik)) andstoring said at least one configuration template at said correspondingnetwork element (NE_(i)); executing at the network element (NE_(i)) thecommand script for said network element (NE_(i)) in a remote mode, fromthe at least one network elements controller (NEC_(k)) and through therespective functional interface (C_(ik)).
 2. Method according to claim1, wherein the step of adding commands for setting an IP interface(D_(ij)) between two network elements (NE_(i), NE_(j)) furthercomprises: allocating an IP address at a first end of said interface(D_(ij)) at one network element (NE_(i)); allocating an IP address at asecond end of said interface (D_(ij)) at the other network element(NE_(j)).
 3. Method according to claim 1, wherein said IP interface(D_(ij)) between two network elements (NE_(i), NE_(j)) is a VLANswitched Ethernet based interface and the step of adding commands tosaid command script for setting an IP interface (D_(ij)) between twonetwork elements (NE_(i), NE_(j)) further comprises the steps of:establishing a VLAN identifier at a first end of said interface (D_(ij))at one network element (NE_(i)); establishing a VLAN identifier at asecond end of said interface (D_(ij)) at the other network element(NE_(j)).
 4. Method according to either claim 1, wherein said interface(D_(ij)) between two network elements (NE_(i), NE_(j)) is implemented bymeans of an IP-based tunnel and the step of adding commands to saidcommand script for setting an IP interface (D_(ij)) between two networkelements (NE_(i), NE_(j)) further comprises the step of establishing aconfiguration of the two ends of said IP-based tunnel, said two endscorresponding to the two network elements (NE_(i), NE_(j)).
 5. Methodaccording to claim 1, wherein said IP interface (Dij) between twonetwork elements (NEi, NEj) is implemented by means of virtual circuittechnology.
 6. Method according to claim 1, wherein the step ofexecuting the command script in a remote mode is performed in aone-by-one mode, for a remote execution of each command in sequence fromsaid command script.
 7. Method according to claim 1, wherein the step ofexecuting the command script in a remote mode is performed in a batchmode for a remote execution of a plurality of commands simultaneouslyfrom said command script.
 8. Method for logical undeployment of a targetIP network comprising a plurality of network elements (NE₁, . . . ,NE_(i), . . . , NE_(j), . . . , NE_(N)) capable of runningnetwork-related processes and supported on a background IP network whichcomprises said network elements (NE₁, . . . , NE_(i), . . . , NE_(j), .. . , NE_(N)) and at least one network elements controller (NEC₁, . . ., NEC_(k), . . . , NEC_(Q)), the background IP network providing IPfunctional interfaces (C_(ik)) between the at least one network elementscontroller (NEC_(k)) and each network element (NE_(i)), and the targetIP network having at least one network-related process been previouslystarted for said at least one network element (NE_(i)); the methodcomprising the steps of: retrieving at the at least one network elementscontroller (NEC_(k)) at least one process information fragment writtenin a text-based information structured language for each network element(NE_(i)), said at least one process information fragment defining saidat least one network-related process and being part of a target networkconfiguration structure; creating, by said at least one network elementscontroller (NEC_(k)), a command script for each network element (NE_(i))based on the target network configuration structure and to be executedat the corresponding network element (NE_(i)); adding to the commandscript generated at the previous step at least a command for stoppingsaid at least one network-related process, using the correspondingprocess information fragment; adding after the commands for stoppingsaid network-related process, and if at least one IP interface (D_(ij))between two network elements (NE_(i), NE_(j)) of the target IP networkhas been previously set and an IP address has been allocated at each twoends of said interface (D_(ij)), at least a command for unsetting saidIP interface (D_(ij)) to each of the two command scripts correspondingto said two network elements (NE_(i), NE_(j)); executing at the networkelement (NE_(i)) the command script for said network element (NE_(i)) ina remote mode, from the at least one network elements controller(NEC_(k)) and through the respective functional interface (C_(ik)). 9.Method according to claim 8, wherein the step of adding commands to saidcommand script for unsetting the IP interface (D_(ij)) between twonetwork elements (NE_(i), NE_(j)) further comprises: removing the IPaddress allocated at a first end of said interface (D_(ij)) at onenetwork element (NE_(i)); removing the IP address allocated at a secondend of said interface (D_(ij)) at the other network element (NE_(j)).10. Method according to claim 6, wherein, if the IP interface (D_(ij))between said two network elements (NE_(i), NE_(j)) is a VLAN switchedEthernet based interface and an VLAN identifier has been previouslyestablished at each end of said interface (D_(ij)), the step of addingcommands to said command script for unsetting the IP interface (D_(ij))further comprises the steps of: removing the VLAN identifier establishedat a first end of said interface (D_(ij)) at one network element(NE_(i)); removing the VLAN identifier established at a second end ofsaid interface (D_(ij)) at the other network element (NE_(j)). 11.Method according to claim 6, wherein, if the IP interface (D_(ij))between two network elements (NE_(i), NE_(j)) is implemented by means ofan IP-based tunnel and a configuration of each end of said interface(D_(ij)) has been previously established, the step of adding commands tosaid command script for unsetting the IP interface (D_(ij)) between twonetwork elements (NE_(i), NE_(j)) further comprises the step of removingthe configuration of the two ends of the IP tunnel, said two endscorresponding to the two network elements (NE_(i), NE_(j)).
 12. Methodfor logical monitoring of a target IP network comprising a plurality ofnetwork elements (NE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N))capable of running network-related processes and supported on abackground IP network which comprises said network elements (NE₁, . . ., NE_(i), . . . , NE_(j), . . . , NE_(N)) and at least one networkelements controller (NEC₁, . . . , NEC_(k), . . . , NEC_(Q)), thebackground IP network providing IP functional interfaces (C_(ik))between the at least one network elements controller (NEC_(k)) and eachnetwork element (NE_(i)), and the target IP network having at least onenetwork-related process been previously started for said at least onenetwork element (NE_(i)); the method comprising the steps of: retrievingat the at least one network elements controller (NEC_(k)) at least oneprocess information fragment written in a text-based informationstructured language for each network element (NE_(i)), said at least oneprocess information fragment defining said at least one network-relatedprocess and being part of a target network configuration structure;creating, by said at least one network elements controller (NEC_(k)), acommand script for each network element (NE_(i))) based on the targetnetwork configuration structure and to be executed at the correspondingnetwork element (NE_(i)); adding to the command script generated at theprevious step at least a command for checking the status of said atleast one network-related process, using the corresponding processinformation fragment; adding, if at least one IP interface (D_(ij))between two network elements (NE_(i), NE_(j)) of the target IP networkhas been previously set, at least a command for pinging the IP interface(D_(ij)) to each of the two command scripts corresponding to said twonetwork elements (NE_(i), NE_(j)); executing at the network element(NE_(i)) the command script for said network element (NE_(i)) in aremote mode, from the at least one network elements controller (NEC_(k))and through the respective functional interface (C_(ik)).
 13. Method forlogical deployment of a target IP network comprising at least twonetwork elements (NE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N))supported on a background IP network comprising said at least twonetwork elements (NE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N))and at least one network elements controller (NEC₁, . . . , NEC_(k),NEC_(Q)), the background IP network providing IP functional interfaces(C_(ik), C_(jk)) between the at least one network elements controller(NEC_(k)) and said at least two network elements (NE_(i), NE_(j)), themethod comprising the steps of: retrieving at the at least one networkelements controller (NEC_(k)) at least one IP networking informationfragment written in a text-based information structured language forsaid at least two network elements (NE_(i), NE_(j)), said at least oneIP networking information fragment defining a IP networking layer forcommunication between said at least two network elements (NE_(i),NE_(j)); creating, by said at least one network elements controller(NEC_(k)), a command script for said at least two network elements(NE_(i), NE_(j)); adding at least a command for setting an IP interface(D_(ij)), being a first end of said IP interface (D_(ij)) at one networkelement (NE_(i)) and a second end of said IP interface (D_(ij)) atanother network element (NE_(j)), to each command script correspondingto said two network elements (NE_(i), NE_(j)); executing at the twonetwork elements (NE_(i), NE_(j)) the command script for said twonetwork elements (NE_(i), NE_(j)) in a remote mode, from the at leastone network elements controller (NEC_(k)) and through the correspondingfunctional interfaces (C_(ik), C_(jk)) respectively.
 14. Method forlogical undeployment of a target IP network comprising at least twonetwork elements (NE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N))supported on a background IP network comprising said at least twonetwork elements (NE₁, . . . , NE_(i), . . . , NE_(j), . . . , NE_(N))and at least one network elements controller (NEC₁, . . . , NEC_(k),NEC_(Q)), the background IP network providing IP functional interfaces(C_(ik), C_(jk)) between the at least one network elements controller(NEC_(k)) and said at least two network elements (NE_(i), NE_(j)), andthe target IP network providing at least one IP interface (Dij)previously set between said two network elements (NEi, NEj), having anIP address allocated at each end of said interface (Dij), said two endscorresponding to the two network elements (NE_(i), NE_(j)); the methodcomprising the steps of: retrieving at the at least one network elementscontroller (NEC_(k)) at least one IP networking information fragmentwritten in a text-based information structured language for said atleast two network elements (NE_(i), NE_(j)), said at least one IPnetworking information fragment defining a IP networking layer forcommunication between said at least two network elements (NE_(i),NE_(j)); creating, by said at least one network elements controller(NEC_(k)), a command script for said at least two network elements(NE_(i), NE_(j)); adding to each command script corresponding to saidtwo network elements (NE_(i), NE_(j)) at least a command for unsettingthe IP interface (D_(ij)) between said two network elements (NE_(i),NE_(j)); executing at the two network elements (NE_(i), NE_(j)) thecommand script for said two network elements (NE_(i), NE_(j)) in aremote mode, from the at least one network elements controller (NEC_(k))and through the corresponding functional interfaces (C_(ik), C_(jk))respectively.
 15. Method for logical monitoring of a target IP networkcomprising at least two network elements (NE₁, . . . , NE_(i), . . . ,NE_(j), . . . , NE_(N)) supported on a background IP network comprisingsaid at least two network elements (NE₁, . . . , NE_(i), . . . , NE_(j),. . . , NE_(N)) and at least one network elements controller (NEC₁, . .. , NEC_(k), NEC_(Q)), the background IP network providing IP functionalinterfaces (C_(ik), C_(jk)) between the at least one network elementscontroller (NEC_(k)) and said at least two network elements (NE_(i),NE_(j)), and the target IP network providing at least one IP interface(Dij) previously set between said two network elements (NEi, NEj),having an IP address allocated at each end of said interface (Dij), saidtwo ends corresponding to the two network elements (NE_(i), NE_(j)); themethod comprising the steps of: retrieving at the at least one networkelements controller (NEC_(k)) at least one IP networking informationfragment written in a text-based information structured language forsaid at least two network elements (NE_(i), NE_(j)), said at least oneIP networking information fragment defining a IP networking layer forcommunication between said at least two network elements (NE_(i),NE_(j)); creating, by said at least one network elements controller(NEC_(k)), a command script for said at least two network elements(NE_(i), NE_(j)); adding to each command script corresponding to saidtwo network elements (NE_(i), NE_(j)) at least a command for pinging theIP interface (D_(ij)) between said two network elements (NE_(i),NE_(j)); executing at the two network elements (NE_(i), NE_(j)) thecommand script for said two network elements (NE_(i), NE_(j)) in aremote mode, from the at least one network elements controller (NEC_(k))and through the corresponding functional interfaces (C_(ik), C_(jk))respectively.